After an electronic device, such as a mobile radio, has been deployed outside of a development phase (for example, after the electronic device is deployed to customers for use), operational problems may occur that may need to be debugged. It is critical, however, that debugging operations be restricted to prevent, for example, unauthorized extraction of sensitive information from the device or unauthorized modifications to the device's operation and settings. A current debugging tool allows a user to telnet to a device (i.e., log into the device using a telnet program) to extract information from the device. The extracted information may then be used in debugging operations and to control certain functions in the device. Typically, “released” devices (i.e., devices that are released to customers and that are no longer in the development phase) are shipped with a limited set of debugging capabilities, whereas, “development” devices (i.e., devices used within a controlled development environment) may be updated/flashed, as needed, with a more comprehensive set of debug capabilities.
In some cases, the limited set of debugging capabilities on a released device may not be adequate. However, it may be impossible to recall the released device and put it in a controlled development environment for debugging with the comprehensive set of debug capabilities. In these cases, it may be necessary to update the released device with the comprehensive set of debug capabilities in the field (i.e., outside of the development environment). However, once a released device outside of a controlled development environment is updated with the comprehensive set of debug capabilities, it may difficult to restrict access to the comprehensive debug capabilities on the released device, and thereby prevent unauthorized access to the comprehensive debug capabilities on the released device.
A flashing tool is typically used to update the operational software on a device. It is also critical that access to the flashing tool be restricted to prevent devices from being updated with unauthorized software. If in the case where it becomes necessary to update the released device with the comprehensive set of debug capabilities in the field, the flashing tool must be also released to perform the updates. Before the flashing tool can update software in secured memory locations on a device, the flashing tool must authenticate itself to the device (i.e., to unlock the device). During the authentication process, the device is configured to query the flashing tool for a secret. In a current method, the device may authenticate the flashing tool if the flashing tool can provide a global shared secret and a secret algorithm. Only a flashing tool with knowledge of these two global secrets may update operational software on a device. Unfortunately, similar to the comprehensive set of debug capabilities, once the flashing tool is released, it may also be difficult to secure the global secrets within the flashing tool. For example, once the flashing tool is released, the global secret may be accessed via an unauthorized reversed engineering process.
One avenue for enabling debugging operations on a device may be to load a lab certificate (a signed digital certificate) into the device and to have the device verify that the lab certificate is loaded on the device at boot time. A lab certificate is typically bound to a particular device such that the lab certificate will only be deemed valid on a device if, at boot time, a bootloader on the device determines that a device identifier in the lab certificate matches a unique identifier in the device. Accordingly, before the lab certificate can used to enable debugging operations and turn on a debugging mode on the device, the lab certificate including the device's unique ID must be created, digitally signed, flashed into the device, and verified by the device at boot time. This approach allows the lab certificate to enable debugging operations on a single released device and cannot be exploited to allow unauthorized debugging operations on other released devices.
After the device is switched to debugging mode, the device may communicate with a remote debugging tool during a debugging session. For example, during the debugging session, the remote debugging tool may communicate with the device to download its memory, put the device into a special mode, and/or retrieve log files from the device. However, if the device with the lab certificate is lost or accidentally released before the comprehensive set of debug capabilities are uninstalled and/or before the lab certificate is removed, anyone with authorized or unauthorized access to the device may be able to perform debugging operations on the device. Also, releasing a tool with the capability to write a lab certificate to the flash memory of a device outside of a development environment is undesirable. As previously mentioned, once the flashing tool is released, it may also be difficult to secure the global authentication secrets within the flashing tool. For example, once the flashing tool is released, the global secret may be accessed via an unauthorized reversed engineering process.
Furthermore, when the lab certificate is employed to enable debugging capabilities, application level instructions for enabling the debugging capabilities are typically carried out by low-level bootloader software that authenticates the lab certificate. The size of the bootloader software is typically severely constrained by hardware requirements and the bootloader software rarely, if ever, gets updated. Therefore, it will be problematic to add application debug-support features to the lab certificate, and more particularly, to update or change debug-support features if those features are to be executed by the bootloader software.
Accordingly, there is a need for a method and apparatus for securing a debugging session.
Skilled artisans will appreciate that elements in the figures are illustrated for simplicity and clarity and have not necessarily been drawn to scale. For example, the dimensions of some of the elements in the figures may be exaggerated relative to other elements to help to improve understanding of embodiments of the present invention.
The apparatus and method components have been represented where appropriate by conventional symbols in the drawings, showing only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the disclosure with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.